On Github you way from time to time need to patch release the previous version of a published release.  This took me longer than I care to admit to understand the steps involved. Hence I'm documenting them in this post. Step 1: Check out the branch corresponding to the previous version of your code. git checkout 7.3.0 Step 2: Fix the bug in the code. Let's say it's a breaking change that's been fixed in the code. Step 3: Commit the changes with a version number that indicates the patch release. Commit the fix git commit -m "Fix bug in 7.3.0" Next, create a new tag git tag 7.4.0 Step 4: Push the changes to the remote repository. git push origin 7.4.0 Step 5: Create a new release for the patch version on GitHub. Navigate to the main page of the repository on GitHub.com, click on the Releases tab, and then click on the "Draft a new release" button. Step 6: Fill in the details for the release in the form, select the tag created from Step 3, and fill in the release notes. Once you have filled in the details, click on the "Publish release" button to publish the release.

You know, it's fuy how the big milestones can sneak up on us. Just as I was putting the finishing touches on my recent Headless Hashnode tutorial, I realized it's been 15 years since I started this blogging jouey—and what's more, I was just 1 post away from blog update 500! It got me thinking about how this whole blogging adventure has shaped my career in web development. I’ve had the same enthusiasm for sharing my experiences as I have for coding, and what better way to commemorate this occasion than to share a bit of that story? Getting started It all started back in 2009 as a university student studying web design at the since-closed Hull School of Art and Design, An early assignment was creating a blog, not even a dynamically driven one - although mine certainly was - and the content expectations were simple too, just a post or 2 for every semester. For me, I began pouring my newfound knowledge into blog posts or tutorials—basic at first, like a PHP script coecting to a MySQL database. As time went on and my understanding broadened, so did the richness of my content. A huge motivation at the time was how helpful this content was for my classmates. I've always loved helping people, and seeing my content become a go-to reference for those around me boosted my confidence to no end. Tinkering and Transformation As the content of my blog evolved so did the blog platform itself. I've always loved deep-diving into how things work, and creating a blog has always been a cycl

Suppose you find yourself in a situation where you need to disable or intercept a console command in Laravel. This tutorial will primarily focus on how to intercept the php artisan migrate command. We'll delve into the command method app/Console/Keel.php and explore how to prevent the migrate command from executing any actions. Inside the command method of app/Console/Keel.php In Laravel 11 use routes/console.php Intercept command You can intercept php artisan migrate and, instead, catch it and use a closure. Artisan::command('migrate', function () { // }); This would essentially stop the migrate command from doing anything. You could then print a message out: Artisan::command('migrate', function () { $this->info('Command NOT AVAILABLE. Use this: php artisan app:migrate'); }); Ruing an alteative command: To run a different command: Artisan::command('migrate', function () { $this->call('app:migrate'); }); In this case, a new command called app:migrate would be executed. Run command with a --path option: Artisan::command('migrate', function () { $this->call('app:migrate', [ '--path' => 'database/migrations' ]); }); Now when ruing php artisan migrate you will get an error: The "--path" option does not exist. The reason for this is the custom command does not have a path option. Lets create the command and add the option. Create a command: php artisan make:command AppMigrate This creates a class called AppMigrate.php inside

Laravel Testing Cookbook will cover common use cases and will be ready in a few months time. Sign up for the waitlist to be notified when it's ready!

The book will cover both PestPHP and PHPUnit. Use the book as a reference for practical examples of testing URLs, Forms, Interactions, Transactions, using third-party API's and more.

Join the waitlist or pre-order at https://laraveltestingcookbook.com/

If you've already used JSON lang in your views, here's a handy package to extract all lang keys to language files. The package exports all your __(‘some text’) calls to language files.

https://github.com/kkomelin/laravel-translatable-string-exporter

Here's a video demo.